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Improvements in and Relating to Wireles s Communication Devices 



The present invention relates to a method of transferring browser information 
and/or parameters between wireless communication devices in a 
telecommunication network, particularly although not exclusively a network 
supporting the Wireless Application Protocol (WAP) and also to apparatus 
therefor. 

As is well known, Internet content and advanced data services can now be 
obtained by users equipped with suitably configured communication devices 
such as mobile radio telephones. In order to provide such services to 
wireless communication devices such as radio telephones, pagers and the 
like, there has been developed a de facto standard known as the Wireless 
Application Protocol (WAP). It allows a wireless communication device to 
communicate over the air with a server connected to the Internet. A Wireless 
Application Environment that is placed on top of the WAP stack includes a 
microbrowser. The browser uses wireless mark-up language (WML), a 
lightweight mark-up language and WMLScript, a lightweight scripting 
language. 

WML implements a card and deck metaphor. The interaction of the browser 
and user is described in a set of cards that are grouped together into a 
document commonly referred to as a deck. The user navigates to a card in a 
deck reviews its content and then navigates to another card in the same deck 
or in a different deck. Decks of cards are transferred from origin servers as 
needed. 
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As the number and variety of content and service providers increases it is 
becoming increasingly apparent that there exists a need to facilitate the 
dissemination of information amongst users of wireless communication 
devices. 

It is thus an aim of the present invention to seek to promote the dissemination 
of information relating to Internet content and service providers. It is a further 
aim of the invention to facilitate the configuration of communication devices to 
obtain more effectively such services. 

Thus, according to one aspect of the invention, there is provided a method of 
transferring resource related information from a first terminal to a second 
terminal of a wireless communication network, wherein at least the first 
terminal is a client of a server connected to an external network and also to 
the wireless communication network which includes the terminals, comprising 
the steps of the first terminal negotiating a connection with the second 
terminal and subsequently transferring the information over the connection. 

Preferably, the information facilitates access to an external network resource 
by the second terminal such as a URL, browser settings or the like. 
Alternatively, the information may have been previously downloaded from the 
external network and could comprise the contents of a web page. Where the 
user and/or the nature of the information requires it, the connection negotiated 
between the terminals should allow real-time transfer of that information. For 
example, the connection could be established as a point to point connection 
utilising circuit or packet switched data. In another situation, perhaps were 
some latency is acceptable and/or in the interests of reducing costs, a 
connection which does not allow real-time transfer of the information may be 
negotiated. 
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The method is particularly suitable for use under the Wireless Application 
Protocol (WAP). The connection may be indirect in the sense that the 
information is transported over the wireless communication network for 
example by SMS (Short. Message Service), CSD (Circuit Switched Data) or 
5 GPRS (General Packet Radio Service), or direct using Infra Red (IR), Low 
Power Radio Frequency (LPRF) or other suitable mechanism. Where the 
method is implemented under WAP, the connection whether direct or indirect 
will conform to the appropriate Wireless (Application Protocol) Datagram 
Protocol (WDP). 

0 

According to another aspect of the invention, there is provided a wireless 
communication terminal for use with the above described method. 



Preferably, the wireless communication terminal comprises a controller 
15 arranged to receive an input of resource related information from another 
terminal, wherein the controller is further arranged to negotiate a connection 
with the other terminal and subsequently to receive the information over the 
connection. A terminal from which the information is transferred may operate 
under the Wireless Application Protocol (WAP) whereas a terminal receiving 
20 the information need not implement WAP although at the expense of reduced 
functionality. 

In order to assist in understanding the present invention, a number of 
embodiments thereof will now be described by way of example and with 
25 reference to the accompanying drawings, in which: 

Figure 1 schematically illustrates a wireless communication device suitable for 
use according to a method of the present invention; 

Figure 2 shows a block diagram of the main elements of the communication 
30 device of Figure 1 ; 
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Figure 3 shows a network including the device of Figure 1 ; 

Figure 4 is a diagram illustrative of the exchange of data between decks in 

accordance with the Wireless Application Protocol; 

Figure 5 illustrates a user interface showing steps in the transmission of 
5 information in accordance with the present invention; 

Figure 6 illustrates the message structure of a text message in accordance 
with the invention; 

Figure 7 illustrate a user interface showing steps in the reception of 
information in accordance with the present invention; and 
10 Figure 8 illustrates a variant of the user interface showing the steps in the 
transmission of the invention in accordance the invention. 

With reference to Figure 1 , there is shown a wireless communication device or 
terminal. The terminal, which is generally designated by 1, comprises a user 

15 interface having a keypad 2, a display 3, an on/off button 4, a speaker 5, and 
a microphone 6. The terminal 1 is adapted for communication via a wireless 
telecommunication network, e.g. a cellular network. However, the terminal 1 
could also have been designed for a cordless network. The keypad 2 has a 
first group 7 of keys as alphanumeric keys, by means of which the user can 

20 enter a telephone number, write a text message (SMS), write a name 
(associated with the telephone number), etc. Each of the twelve 
alphanumeric keys 7 is provided with a figure "0-9" or a sign "#" or "*", respec- 
tively. In alpha mode, each key is associated with a number of letters and 
special signs used in text editing. 

25 

The keypad 2 additionally comprises two soft keys 8, two call handling keys 9, 
and a navigation key 1 0. 

The two soft keys 8 have a functionality corresponding to what is known from 
30 the terminals manufactured by Nokia under the following designations: Nokia 
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2110™, Nokia 8110™ and Nokia 3810™. The functionality of the soft key 
depends on the state of the terminal and the navigation in the menu by using 
a navigation key. The present functionality of the soft keys 8 is shown in 
separate fields in the display 3 just above the keys 8. 

5 

The two call handling keys 9 are used for establishing a call or a conference 
call, terminating a call or rejecting an incoming call. 

The navigation key 10 is an up/down key and is placed centrally on the front 
10 surface of the terminal between the display 3 and the group of alphanumeric 
keys 7. Hereby the user will be able to control this key by simply pressing the 
up/down key using his/her thumb. Since many experienced terminal users 
are used to one-hand control, it is a very good solution to place an input key, 
requiring precise motor movements. Thus, the user may place the terminal in 
15 the hand between the fingertips and the palm of the hand, leaving the thumb 
free for inputting information. 

Figure 2 .schematically shows the elements of the terminal 1 . The terminal 1 
is adapted for use in connection with a GSM network, but, of course, the 
20 invention may also be applied in connection with other phone networks, such 
as other kinds of cellular networks and various forms of cordless terminal 
systems or in dual band terminals accessing sets of these systems/networks. 
The microphone 6 records the user's speech, and the analogue signals 
formed thereby are AID converted in an A/D converter (not shown) before the 

25 speech is encoded in an audio part 14. The encoded speech signal is 
transferred to controller means 18, which may support software in the 
terminal. The controller means 18 also forms the interface to the peripheral 
units of the apparatus, including a RAM memory 17a and a Flash ROM 
memory 17b, a SIM card 16, the display 3 and the keypad 2 (as well as data, 

30 power supply, etc.). The controller means 18 communicates with the 
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transmitter/receiver circuit 19. The audio part 14 speech-decodes the signal, 
which is transferred from the controller 18 to the earpiece 5 via a D/A 
converter (not shown). 

5 The controller means 18 is connected to the user interface. Thus, the 
controller means 18 monitors the activity in the terminal and controls the 
display 3 in response thereto. 

Therefore, the controller means 18 detects the occurrence of a state change 
1 0 event and changes the state of the terminal and thus the display text. A state 
change event may be caused by the user when he activates the keypad 
including the navigation key 10, and these type of events are called entry 
events or user events. However, the network communicating with the 
terminal may also cause a state change event. This type of event and other 
1 5 events beyond the user's control are called non user events. Non user events 
comprise status change during call set-up, change in battery voltage, change 
in antenna conditions, message on reception of SMS, etc. 

Figure 3 schematically shows a network 50, comprising a server computer 20 
20 and a plurality of terminals or clients 1a, 1b and 1c. The server 20 and the 
clients 1 support the Wireless Application Protocol (WAP). The WAP content 
and its applications are specified in a set of well-known content formats based 
on the familiar WWW content formats. WAP is disclosed in the Wireless 
Application Protocol Architecture Specification; Version 30-Apr-1998; by 
25 Wireless Application Protocol Architecture Working Group. 

When transporting content between the client 1 and the server 20, the content 
is transported using a set of standard communication protocols based on the 
WWW communication protocols known as the Wireless Datagram Protocol 
30 (WDP). A browser in the client 1 co-ordinates the user interface and is 
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analogous to a standard web browser. The client 1 is provided in an 
environment, which makes it possible to reach a wide variety of different 
wireless platforms, e.g. World Wide Web (WWW). The environment provided 
may be referred to as Wireless Application Environment (WAE). This means 
5 that the client 1 may be supported by some kind of browser, e.g. a micro- 
browser, to access the different services connected to the server 20. In order 
to access the services, the browser includes the following functionalities: 

• Wireless Markup Language (WML) - a lightweight Markup language, similar 
to HTML, but optimised for use in hand-held mobile terminals; 

1 0 • WML Script - a lightweight scripting language, similar to JavaScript™; 

• Wireless Telephony Application (WTA, WTAI) - telephony services and 
programming interfaces; and 

• Content Formats - a set of well-defined data formats, including images, 
phone book records and calendar information. 

15 

The server 20 supporting the Wireless Application Protocol is connected to a 
gateway 30 or in a non-illustrated variant, the gateway and server may be 
implemented together. The gateway 30 is also a kind of server, which 
identifies and encodes /decodes information between the client 1 and the 

20 server computer 20. This means that the gateway 30 is provided with 
encoders and decoders (not shown). In addition, the server 20 may comprise 
different algorithms to carry out encrypting/decrypting The 
encrypting/decrypting itself may be performed by well-known methods, e.g. 
RSA, Diffie-Hellman, etc. The server computer 20 may comprise different 

25 scripts to support WAP and data to be accessed by the client. This data may 
comprise all kinds of information, e.g. weather reports, news, information from 
stock markets, etc. 

In order to access the server computer 20, from the client 1 , the server 20 is 
30 connected to a wireless telecommunication network 50, e.g. a cellular 
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telephone network. The network 50 comprises memory means (not shown), 
which is arranged to identify the identification means from the client 1. The 
memory means can be e.g. a database, comprising information about 
different subscribers of the network. Thus, when a client 1 tries to establish a 
5 connection to the network, the network determines if the client 1 is stored in 
the memory means in which case access is allowed to the network 50. The 
manner by which a client 1 establishes a connection to the network 50 is well 
known in the art and no further description thereof is considered necessary. 

10 Once a connection has been established to the network 50, and the client 1 is 
operating in the WAE then data can be transported between the client 1 and 
server 20 via the gateway 30 at the request of a user of the client 1 . The 
manner in which the user interacts with the client is well known from the 
above WAP documentation. Thus, the interaction of the browser and user is 

15 described in a set of cards that are grouped together into a document 
commonly referred to as a deck. The user navigates to a card in a deck 
reviews its content and then navigates to another card in the same deck or in 
a different deck. Decks of cards are transferred from the server 20 as 
needed. 

20 

In more detail, and with reference to Figure 4, there is shown a Main Deck 60 
comprising three cards: a Start Card 61, an Option Card 62 and an Exit Card 
63. On activation of a WAP session, the Main Deck 60 is loaded into the 
browser and the Start Card 61 is automatically activated. The start card 61 
25 has a first portion 61a which defines a number of parameters each of which is 
assigned a value reflecting the value of the parameter in a "master copy" (not 
shown) of the content stored in the server 20. The second portion 61b of the 
Start Card 61 updates the parameter values to reflect the value of the 
parameters stored locally in the client 1. The second portion 61b sequentially 
30 effects access to Link Decks 64 that form the second level in the hierarchy, 
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each of which respectively effects access to a WML Deck 65 and Storage 
Deck 66 in a third layer of the hierarchy. Thus the second portion 61b 
ensures that the Link Decks 64, WML Deck 65 and Storage Deck 66 are 
loaded into a client cache from the server 20 if not already there. The WML 
Deck 65 comprises content such as an email or news piece, whilst a 
corresponding Storage Deck 66 contains parameters associated with the 
WML Deck 65 such as whether the email or news piece has been read 

The Option card 62 is entered on reaching the end of the Start Card 61. The 
Option card 62 has a number of portions, each of which is associated with a 
defined one of the Link Decks 64 in the second layer of hierarchy. On 
entering the Option Card 62, the portions are automatically activated, 
sequentially creating user selectable links to the WML Deck 65 on the display 
of the terminal 1. Activation by the user causes the browser to access the 
selected WML Deck 65 in the third layer of hierarchy. The browser first tries 
to load the Deck 65 from the cache and if unsuccessful requests its transfer 
from the server 20. 

The Exit Card 63 is accessed when the application entered through the Main 
Deck 60 is exited. The exit card 63 is used to keep the "master records- 
stored in the server 20 in line with the records stored and updated in the 
browser. The storage decks 66 each store parameters that may vary during 
an application session. For example the parameter indicating whether a mail 
or news piece has been read will change if the WML deck 65 containing the 
email or news is accessed also a parameter may indicate that the user has 
chosen to delete a news piece or email. The exit card 63 creates a message 
that identifies the new values of the changed parameters and sends it to the 
server 20. 
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In the event that a user (hereinafter the sender) locates resource related 
information such as a service or content which he believes might be of 
interest to another party (hereinafter the recipient) he may wish to provide the 
relevant information to that recipient. In the following, it is assumed that all 
the terminals 1 can communicate with the network 50. 

Referring to Figure 5, where the sender is viewing content in the form of a 
WML deck 65, he can, by depressing a suitably programmed softkey 8 obtain 
access to a menu 70 which permits him to select the content he wishes to 
send, either a URL of the presently viewed Deck 65 or the Deck 65 itself. The 
sender is then provided with a further menu 71 from which he must choose 
the bearer he wishes to use to transport the content, e.g. SMS, Infra Red (IR), 
Circuit Switched Data (CSD) or Low Power RF (LPRF) or General Packet 
Radio Service (GPRS). An Editor 72 gives the sender access to a list of 
names and associated addresses, be they telephone numbers or URLs, to 
whom the sender may wish to send the content. Alternatively, the sender 
may simply enter the required address directly into his terminal 1a. Once 
provided with an address, the sender's terminal 1a is ready to attempt to 
deliver the content to the recipient's terminal 1 b. 

However, in the particular case of transmission via Infra Red the receiving 
terminal does not need to be identified. By simply establishing a line of sight 
connection between the terminals, the content may be sent direct to the 
receiving terminal. 

In the case where the content is a Deck 65, the sender's terminal 1a firstly 
attempts to establish a connection-oriented session with the recipient's 
terminal 1b by firstly sending a connectionless push to a registered WDP port 
on the terminal 1b which is processed by a Session Initiation Application (SIA) 
resident on the receiving terminal 1b. Clearly, if the receiving terminal 1c is 
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not WAP enabled, it might receive this message but does not react to it. As a 
result, the transmitting terminal does not receive a receive acknowledgement 
message. Consequently, the transmitting terminal can assume after a certain 
time that the push was not successful. This might be indicated to the sending 
terminal by a time-out timer. The sender will then be provided with the option 
via the Ul of sending the content as a text message via SMS as is set out in 
more detail below. However, assuming the receiving terminal 1b is WAP 
enabled, it is now alerted to the need to receive a WAPpush and providing the 
recipient has configured the terminal 1b to allow the establishment of sessions 
by this mechanism, a session commences. Otherwise, a message is 
dispatched to the sender's terminal indicating that delivery of the pushed 
content is not possible. 

Once the session has been established, the sender's terminal 1a is able to 
issue a WAP push command which causes the content to be transported to 
the recipient's terminal 1b. The next step will depend on the capabilities of 
the recipient's terminal 1b. If the terminal 1b is capable of supporting multiple 
browsers or user agents, then the Deck 65 will be routed to a new user agent 
which runs in the background and which may subsequently be selected by the 
recipient via the Ul of his terminal 1b to move the currently in use user agent 
to the background and to replace it in the foreground with the received Deck 
65. Alternatively, where the terminal 1b can support a single browser or user 
agent only, the recipient will be prompted via the Ul to exit the existing Deck in 
favour of the received Deck 65. In such circumstances where the recipient 
elects not to exit the existing user agent, a message will be delivered to the 
sender's terminal 1a indicating the rejection of the content 65. Optionally, the 
user might have the possibility to save the pushed message into a memory of 
his terminal for later use. 
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In the event that the receiving terminal 1c is not WAP enabled, the sender 
may send the content via the standard SMS route. This method may be 
selected by the sender initially where he knows that the recipient does not 
have a WAP enabled terminal 1c, or more likely following an unsuccessful 

5 attempt to initiate a WAP session as set out in the preceding paragraph. In 
either case, an application in the sending terminal 1a extracts the textual 
content from each card of the deck 65 and pastes it into one or more SMS 
text messages for transport according to the bearer selected by the sender. 
Thus, the content may be transported as an SMS over the network via the 

10 SMSC or directly between the terminals 1a,1c using IR or LPRF. The SMS 
text message(s), once received by the receiving terminal, may be viewed in a 
conventional manner. 

Turning now to the situation where the content is a URL, Figure 6 shows the 
15 format of a URLCard 80 as an SMS text message. The data for inclusion in 
the URLCard 80 is extracted from the corresponding Deck 65 and stored as a 
title T 81 and web address or URL U 82. The URLCard 80 includes a header 
83 which identifies the nature of the URLCard 80 to an application on the 
receiving terminal 1b 

20 

In use, the URLCard 80 is generated from the Deck 65 as described in the 
preceding paragraph using an application in the sender's terminal 1a. The 
push mechanism described above in relation to the Deck 65 as content is 
used to transport the URLCard to the receiving terminal 1b. Thus, the Card80 

25 may be transmitted as an SMS text message via a conventional Short 
Message Service Centre (SMSC) which routes the URLCard 80 to the 
terminal 1b identified as the recipient. Alternatively, where the sender and 
receiver are in close proximity the URLCard 80 may instead be transferred 
directly between the terminals using IR or LPRF as selected by the sender. 

30 As illustrated in Figure7, following receipt by the recipient terminal 1b, the 
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URLCard 80 it is identified by the application resident in the terminal 1b as 
being in the form of an SMS text message 90. The application then 
recognises the header 83 and determines that the URLCard contains a URL. 
Subsequently, the Title 81 and URL 82 are extracted by the terminal and 
when selected by the recipient this data is displayed 91 together with a legend 
next to the suitably programmed softkey 8 the depression of which softkey 8 
causes the browser to be launched 92 and connection to the URL attempted. 

In the event that the receiving terminal 1c is not WAP enabled, the sender 
may elect to send the content via the standard SMS text message route. This 
method may be selected by the sender initially where he knows that the 
recipient does not have a WAP enabled terminal or more likely following an 
unsuccessful attempt to initiate a WAP session as has been described above 
in relation to the Deck 65 as content. In either case, an application in the 
sending terminal 1a extracts the URL and title from the relevant Deck 65 and 
pastes it into one or more SMS text messages for transport according to the 
bearer selected by the sender. Thus, the content may be transported as an 
SMS text message over the network or directly between the terminals using 
IR or LPRF. The SMS, once received by the receiving terminal 1c, is viewed 
in a conventional manner. Clearly, where the receiving terminal 1c is not 
WAP enabled, it will not be possible to launch a browser to access the URL 
from the receiving terminal. In which case, although the URLCard 80 may be 
displayed as an SMS, no option will be given via the softkey to launch a (non- 
existent) browser. 

In the case where the contents are the browser settings for a gateway 
necessary to access a specific service they are stored in an SMS text 
message format with an appropriate identifier in the header and through the 
WAPpush mechanism set out previously in relation to the Deck and URL 
content, the content is transmitted to the receiving terminal 1b. Different 
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services may be accessed through one gateway via the same settings in the 
terminal. In the event that the receiving terminal 1c is not WAP enabled, the 
content will be rejected in the manner described (time out a sending terminal) 
above in relation to the other forms of content. Although the option of sending 

5 the content via the SMS route could be carried out there does not seem to be 
any practical benefit in sending such content to a non enabled terminal 1c. 
However, assuming the receiving terminal 1b is WAP enabled, an application 
resident on the receiving terminal 1b identifies that the content is a browser 
setting from the header of the SMS text message. The application then 

10 prompts the recipient, via the Ul. to either discard the browser settings or to 
store them in the terminal for later use. 

It will be understood that where reference is made in the foregoing to an 
application for processing the content for either transmission or reception, this 
15 lies within the abilities of those skilled in the art. It will further be appreciated 
that in the interest of minimising the complexity of a user interface, the 
decision on which bearer to use for the connection may be under software 
control. Figure 8 is illustrative of a variant of the transmission process 
described above in relation to Figure 5 in which the user simply selects the 
20 recipient of the resource information from his phone book, for example and 
under software control the sending terminal, as part of the negotiation 
process, identifies the most suitable bearer depending on the capability of 
each terminal. The user may be provided with the ability to select a preferred 
mode for the connection, i.e. the least expensive in which case the sending 
25 terminal might choose to send a URL to the receiving terminal rather than an 
entire web page which would require much greater resources. Furthermore, 
where the user wished to use a line of sight bearer such as IR then this would 
override the software selection process set out above. 
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A method of transferring resource related information from a first 
terminal to a second terminal of a wireless communication network, 
wherein at least the first terminal is a client of a server connected to an 
external network and also to a wireless communication network which 
includes the terminals, comprising the steps of the first terminal 
negotiating a connection with the second terminal and subsequently 
transferring the information over the connection. 

>. A method as claimed in Claim 1 , wherein the second terminal is also a 
client of a server connected to the external network and the information 
facilitates access to an external network resource by the second 
terminal. 

3. A method as claimed in Claim 1 or Claim 2, wherein the information 
comprises a URL. 

4. A method as claimed in Claim 2, wherein the information comprises 
20 browser settings for use by the second terminal. 

5. A method as claimed in any preceding Claim, wherein the information 
has been previously downloaded from the external network. 

25 6. A method as claimed in Claim 5, wherein the information comprises a 
web page. 

7. A method as claimed in any preceding Claim, wherein the negotiation 
of the connection includes specifying the bearer to be used in 
30 transporting the information to the second terminal. 



A method as claimed in Claim 7, wherein the bearer is specified i 
accordance with a pre-determined user preference. 



A method as claimed in any preceding Claim , wherein the connection 
is made via the wireless communication network. 

A method as claimed in any one of Claims 1 to 8, wherein the 
connection is made directly between the terminals. 

A method as claimed in Claim 10, wherein the connection comprises 
an infra red link. 

A method as claimed in Claim 10, wherein the connection comprises a 
low power radio frequency link. 

A method as claimed in any preceding Claim, wherein the negotiation 
of the connection comprises sending a request from the first terminal to 
the second terminal for approval to establish a connection between the 
terminals and on receiving approval from the second terminal 
establishing the connection. 

A method as claimed in Claim 2 and any claim appendant thereto, 
wherein both terminals are using a Wireless Application Protocol and 
the request is sent to the second terminal using a connectionless push 
command. 

A method as claimed in Claim 14, wherein the connection is 
established using a bearer indicated in the connectionless push 
command. 
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16. A method as claimed in any preceding Claim, wherein the external 
network resource is a server. 

5 17. A method as claimed in Claim 2 and any Claim appendant thereto, 
wherein both terminals are using a Wireless Application Protocol and 
the resource information comprises a WAP deck. 

18. A method as claimed in Claim 17, wherein the transfer of the WAP 
10 deck to the second terminal includes the step of substituting the WAP 

deck with a pre-existing WAP deck on the second terminal. 

19. A method as claimed in Claim 18, wherein the pre-existing WAP Deck 
is deleted following the substitution step. 

15 

20. A method as claimed in Claim 1, wherein the external network is the 
Internet. 

21. A wireless communication terminal arranged to access an external 
20 network resource via a wireless communication network, the terminal 

comprising a controller arranged to receive an input of resource related 
information from another terminal, wherein the controller is further 
arranged to negotiate a connection with the other terminal and 
subsequently to receive the information over the connection. 



25 



22. A terminal as claimed in Claim 21, wherein the controller operates in 
accordance with a Wireless Application Protocol. 



30 



23. 



A terminal as claimed in Claim 22, wherein the controller is arranged to 
receive the resource related information via a push command. 



>4 f ^ 
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24. A terminal as claimed in any one of Claims 21 to 23, wherein the 
terminal is a cellular radio telephone. 

5 25. A wireless communication terminal arranged to access an external 
network resource via a wireless communication network, the terminal 
comprising a controller arranged to send resource related information 
to another terminal, wherein the controller is further arranged to 
negotiate a connection with the other terminal and subsequently to 

1 0 send the information over the connection. 

26. A terminal as claimed in Claim 25, wherein the controller operates in 
accordance with a Wireless Application Protocol. 

15 27. A terminal as claimed in Claim 26, wherein the controller is arranged to 
send the resource related information via a push command. 

28. A terminal as claimed in any one of Claims 25 to 27, wherein the 
terminal is a cellular radio telephone. 



20 
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Abstract 

Im provements in and Relating to W ireless Communication Devices 

A telecommunication network is described in which information relating to 
access to resources such as the world wide web, may be transferred between 
wireless communication terminals at least one of which is a client of a server 
connected to the network and providing access to the resources. A method of 
transfer and a terminal suitable therefor are described. 
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